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CP-67/CMS is a time-sharing system that provides easy, conversa- 
tional use of a terminal-oriented IBM System/360 data-processing 
configuration. The system has two independent components: the Con- 
trol Program (CP-67) which manages the resources of a System/360 
Model 67 such that remote users appear to have a dedicated System/ 
360 at their disposal; and the Cambridge Monitor System (CMS), a 
conversational operating system designed to provide a wide range of 
capabilities through relatively simple commands at a terminal. CP- 
67/CMS was developed at the IBM Cambridge Scientific Center. 


Users communicate with the system through commands that cause com- 
pilation, file creation, and numerous other operations. Familiarity 
with the entire command set is not necessary in order to use the system; 
typically, if the system is to be used for an occasional Fortran compila- 
tion and execution, a knowledge of only two or three commands will be 
sufficient. Should the user's needs be more varied, however, numerous 
commands are provided which support many complex operations. 
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ii Components of the System 


The CP-67/CMS time-sharing system consists of two independent 
components: the Control Program (CP-67) and the Cambridge Monitor Sys- 
tem (CMS). The Control Program creates the time-sharing part of the 
system to allow many users to simultaneously perform work. The Cambridge 
Monitor System provides the conversational part of the system to allow a user 
to monitor his work in a conversational manner. 

Both components are independent of each other. CP-67 can be used 
on an appropriate configuration without CMS and CMS can be run on a properly 
configured System/360 as a single-user system without CP-67 (see Appendix 
A and B for appropriate configurations). If CP-67 is used without CMS, an 
operating system or systems must be chosen to provide the conversational 
or production aspect of the system as CP only provides the time-sharing cap- 
ability. 

CP-67 is capable of running any System/360 operating system (includ- 
ing OS/360 and DOS) as long as that system does not include any timing de- 
pendencies or self-modifying I/O sequences. CP-67 is also capable of running 
any System/360 operating system along with CMS in a multi-programming mode 
concurrent with its usual time-shared, multi-access operation. If the System 
/360 operating system contains telecommunication facilities, CP will allow 
that system to control the 2702 transmission control unit and the user to DIAL 


into that system. 
ik System Environment 


The environment of CP-67 is one of "virtual machines". A virtual ma- 
chine is a functional simulation of a real computer and its associated I/O de- 


vices. CP-67 builds and maintains for each user a virtual System/360 machine 


from a predescribed configuration. The virtual 360 is indistinguishable to 

the user and his programs from a real System/360, but it is really one of 
many that CP-67 is managing. CP allocates the resources of the real ma- 
chine to each virtual machine, in turn, for a short ''slice"' of time, then moves 
on to the next virtual machine - thus, time-sharing. 

Since the virtual machines are simulated, their configurations may 
differ from each other and from the real machine. For instance, the real 
machine may have 512K and eight disk drives and the virtual machine can 
have 768K and two disk drives. One virtual machine may have a virtual 2702 
and run an OS-based system and another virtual machine that does not have a 
virtual 2702 may run CMS. One virtual machine may have a remote printer 
and a remote card punch while another virtual 360 may have a dedicated 
printer and 2250. Regardless of the configuration, each user controls his 
virtual machine from his terminal, which is, effectively, his console key- 
board, 

Like real machines, virtual machines will operate most efficiently under 
an operating system. The Cambridge Monitor System (CMS) is designed to 
allow full use of a System/360 through a simple command language entered at 
the console (in the case of a virtual machine, at the terminal), CMS gives the 
user a full range of capabilities -- creating and managing files, compiling and 
executing problem programs, and debugging -- using only his remote terminal. 
Since each user has his own virtual machine with his own copy of CMS residing 
"in it', nothing he does can affect any other user; if he destroys the CMS nu- 
cleus or abends the CMS system, he can re-IPL his virtual machine and con- 
tinue without disturbing other users. In addition, since users cannot get "out- 
side" their virtual machines, CP-67 is protected from any user error. CMS 


also provides a batch monitor for compile, load, and go type jobs coming from 


tape and cards. The batch monitor can be run from a virtual machine as a 


background system with conversational CMS users on other virtual machines. 


Ill. The Control Program - 67 


Before a user is authorized to use CP, he must be assigned a USERID, 
which identifies him to the system, and a password, which is checked when he 
"logs in". Associated with each USERID is a table describing the virtual ma- 
chine assigned to that user. Whenever he logs in, CP sets up this virtual 360 
machine for him. Although all the virtual machines may be different, most 
will be set up with the configuration expected by CMS, the most commonly used 
operating system. They will include at least 256K bytes of core storage, two 
disk drives, a console (the terminal), a card-read-punch unit, and a printer. 
The real system will usually have a larger number of disk drives and/or a 
drum, tape drives, and perhaps more core storage. 

Because there is not room in real core for all users! virtual core, a 
technique called 'paging''is used by the system. Virtual core is divided into 
4096-byte blocks of storage called 'pages''. All but currently active pages are 
kept, by the system, on direct access secondary storage; as active and inactive 
pages change status they are "paged" in and out of real core on a demand basis. 
While the paging operation is being perfomed for one virtual machine, another 
virtual machine can be operating. The paging operation, and resultant alloca- 
tion of real core to a given user's pages, appear random to the system. Special 
hardware is provided on the System/360 Model 67 that translates, at execution 
time, the user's (or user program's) addresses into the current real addresses 
of the randomly located pages. This is called ''dynamic address translation"; it 


is transparent to the user. 


Because of the virtual machine concept employed by this system, only 
the Control Program (CP) may operate in the supervisor state on the real ma- 
chine. All programs other than CP - that is, all programs executing on vir- 
tual machines — operate in the problem state on the real machine. By a special 
interrupt-handling procedure, however, CP supports what amounts to a virtual 
supervisor state on the virtual machine. All user interrupts, including those 
caused by attempted privileged operations, are handled by CP, which then re- 
flects to the user program only those the user program would expect from a 
real machine. The user may expect his programs to execute on his virtual ma- 
chine in a manner identical to their execution on a real System/360. 

All virtual machine I/O operations are handled by CP, which must trans - 
late them into real machine I/O operations. This requires two translations, 
accomplished as follows: CP intercepts all user I/O when Start I/O is issued. 

It translates virtual device addresses into real device addresses, translates 
virtual core storage addresses into real core storage addresses, ensures that 
all necessary pages are in real core storage, builds a CCW string for the user, 
and issues SIO when the channel is free. When CP receives an interrupt indi- 
cating I/O completion, it sets a "ready-to-run" flag in the user's virtual ma- 
chine status table; when control is returned to the virtual machine, the proper 
I/O interrupt is simulated. The virtual machine is not given control from the 
time it issues an SIO until CP delivers the simulated I/O interrupt. In the mean- 
time, another virtual machine(s) may be operating. 

All virtual machine unit record I/O is spooled onto disk by CP. Thus, 
any card deck to be "'read'' by a virtual machine must have been read by CP 
prior to the user's call for it on his virtual machine or transferred to that user 
from another user's files via the XFER console function in CP; the physical 


deck must have been preceded by a card containing the USERID, so that CP can 





@ 


know who the card-image file is for. Later, when the virtual machine has 
"read" the card deck, a card reader end-of-file is simulated. Card and 
printer output, similarly spooled, is not queued for physical output until CP 


is notified of end-of-file in one of three ways: the user logs off the system 





(end-of-file is assumed); the CLOSE console function specifies the (virtual) 
address of the device to be closed; or CP detects an invalid CCW addresses 
to the device (end-of-file is assumed). Further output for a closed device is 
assumed to start a new file. So that the system operator can separate physi- 
cal output, printed and punched output files are always preceded by a record 
(supplied by CP) that contains the USERID. 

The CP console functions allow the user to control his virtual machine 
from the terminal much as an operator controls a real machine. To perform 
an IPL, for instance, the user types "IPL" and a device address or the name 
of a 'named" operating system, such as CMS. The user can stop his virtual 
machine at any time (by depressing the ATTN key) and request display of any 
portion of his storage and registers. He can modify the contents, if desired, 
and restart his machine. CP also recognizes a few special purpose commands, 
such as the XFER function mentioned above, the QUERY function to obtain the 


number of users on the system and their USERID's, the MSG function to com- 





municate with other users, the TIMER function to control the interval timer, 
the DIAL function to connect the terminal to a telecommunications-based opera- 
ting system, and the ATTACH and DETACH functions to add or remove I/O de- 
vices from a virtual machine configuration (ATTACH can only be issued by the 
OPERATOR). See Section V for a brief description of the CP-67 console func- 


tions. 


Iv. 


operating system, capable of running on a real machine as well as on a virtual 


machine. 


The Cambridge Monitor System 


The Cambridge Monitor System (CMS) is a single-user, conversational 


It interprets a simple command language typed in at the operator's 


console (in this case, the user's remote terminal), 


ing machine configuration: 


1052 
2311 
oli 
© 2311 
1403 
2540 
2540 
* 2400 
* 2400 


‘virtual 
address 


009 
190 
191 

192 
00E 
00C 
00D 
180 
181 


symbolic 


name 


CONI1 
DSK1 
DSK2 
DSK3 
PRN1 
RDRI 
PCHI1 





TAPI 
TAP2 


At least 256K bytes of core storage. 


erent addresses and/or different devices. 


console 

system disk (read-only) 
permanent disk (user files) 
temporary disk (work space) 
line printer 

card reader 

card punch 

tape drive 

tape. drive 


* The 2311 for the temporary disk and the two 2400 tape urives 


are optional devices; they are not included in the-minimum configuration, 


Whether running on a real or a virtual machine, CMS expects the follow-" 


.) 


Under CP, of course, these devices are simulated and remapped to diff- « 


For instance, CMS expects a 1052 


printer-keyboard operator's console, but most remote terminals are 2741's; 


CP handles all channel program modifications necessary for this simulation. 








Under CP, all CMS users share the read-only system disk; on it 
reside the CMS nucleus routines, which the user IPL's, and the other rou- 
tines and libraries that CMS calls as needed. The CMS nucleus is also 
shared in core among users under CP, but users may modify the CMS nu- 
cleus as they wish without affecting either the system disk version or the 
copies in other virtual machines. If a user modifies the CMS nucleus, he 
will no longer share the nucleus with other users but will obtain his own 


copy of the nucleus. 
File Management Under CMS: 


Each CMS user is assigned two disks (a third disk is optional), one of 
which is shared with other CMS users. These disks, under CP, are seldom 
complete disk packs. At the time a user is authorized to use CP-67/CMS, the 
size of each disk area is set by the system administrator, according to the 
needs of the user and the total amount of disk space available. 

The shared disk contains the CMS nucleus, which is loaded into the 
virtual machine by the IPL console function, Also on this disk, referred to as 
the ''system (SY) disk'' are CMS commands which are not core-resident, and 
system libraries of routines and macros. No user may write on this disk as 
it is read-only. Any attempt to modify any of the system files results in an 
error message. 

The two other disks are known as the "permanent"! and ''temporary" 
disks. The user does not normally share these disks with any other user, 
as they are accessible only to him after he has logged in with the correct 
USERID and password. The permanent disk is used for files which are to be 


saved from one terminal session to the next. The temporary disk, which is 


optional, provides space for work files which need not be retained between 
sessions. This disk is erased whenever the user logs out. 

If a user knows the correct password, additional permanent disks can 
be concatenated or ''linked'' to his permanent disk to allow file-sharing among 
esee, 

CMS uses a three-field file identification to catalog both system and user 
files. The fields are referred to as the filename, filetype, and filemode of the 
file. Uniqueness of any one of the fields is sufficient to differentiate a file from 
other files. CMS maintains a directory (the ''User File Directory") of each 
user's files, which includes information on the file format, size, and location, 
This allows the user to specify files by using only the file identification or a 
portion of it. 

All CMS disk files are written in 800-byte physical records. The sys- 
tem I/O routines handle packing of logical records into this format. The re- 
cord blocks are written onto the user's disk area in random order. CMS main- 
tains chains of disk addresses to keep track of the files. These chains are 
linked to the User File Directory, which has an entry for each user file. The 
directory is brought into storage when the user logs in, and is updated when- 
ever files are used. Periodically, and at least as often as once per command, 
the updated file directory in core is written out onto disk, so that the perman- 
ent copy is as current as possible. This insures an accurate directory if it is 
necessary to re-IPL CMS during a terminal session. 

The directory handles files up to 12. 8 million bytes in length, which is 
56 cylinders of a 2314 disk pack and is beyond the capacity of an entire 2311 
disk pack. In practice, the user's disk will not normally require files of that 


length, since the typical user uses less than 25 cylinders. Whenever CMS de- 


“File-sharing is currently being debugged. 


~~ 


tects that only a few tracks are left on the user's disk, a warning message is 
typed, and the files currently open are closed. A program or command in ex- 
ecution is halted, so the user may create more free space on the disk by eras- 
ing some files, or copying them from disk to other media. 

Although most of the CMS commands operate on disk-resident files, the 
user also has access to the card-read-punch, printer, and tape drives. The 
commands, in general, create sequential files of fixed-length records; however, 
the programmer using the CMS I/O support routines is able to use any record 
format with either fixed-length or variable-length records. 

Files are automatically "opened" for reading or writing when the first 
read or write is issued. Only eight files may be open at the same time. CMS 
routines automatically close files after every command, and after user pro- 
grams that complete normally. If a user program needs to access more than 
eight files during execution, the FINIS command must be called to close some 


files. Files must also be closed between writing and reading. 


CMS Commands: 


CMS commands fall naturally into four categories: file manipulation, 
compilation, execution austere, and debugging aids. 

The file handling commands allow the user to create, copy, move, com- 
bine, update, print, compare, and erase disk files. Other commands provide 
access to the tape units, printer, and card-read-punch. Under the CMS linkage 
scheme, all of these commands are available to executing programs as well as 
to the user at the terminal. 

The CMS language processors are the same ones used under Operating 
System/360 (OS); these include Assembler (F), FORTRAN IV (G), and PL/I(F). 
The Assembler produces object programs that may be executed under either 


CMS or OS, depending on the macros used in the source program. Special file- 
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handling routines for macro libraries are included. The FORTRAN and PL/I 
compilers also produce OS-compatible object programs. (The FORTRAN ex- 
ecution —time support programs have been modified for CMS.) The SNOBOL 
compiler and assembler-interpreter were adapted from programs designed to 
execute under OS, 

The execution control commands allow the user to load his programs 
from single object decks called TEXT files (the filtype TEXT is reserved for 


relocatable object programs) or from a library of programs. He can pass a 





list of parameters to his program from the terminal, and specify the point at 
which execution is to begin. To avoid relocation (bypass the relocating loader) 
he can create a file consisting of an image of the portion of core storage con- 
taining his program, and load that non-relocatable copy back at any time. Since 
the loading commands can be accessed by executing programs, overlay struc- 
tures may be set up. The user can also create a file which is a series of com- 
mands, and then execute these commands by typing a single line; logic state- 
ments can also be placed in the file with the commands such that if errors 

occur from a command, no more commands will execute from that file. 

The debugging command in CMS is called DEBUG. It allows the user to 
stop his programs at beeadatecunined points and examine his registers, PSW, 
and storage, and modify these if he so desires. This information may be typed 
out at his terminal or printed offline. A program interrupt gives control to 
DEBUG, as does the external interrupt caused by the EXTERNAL console func- 
tion, The user may also employ the program tracing routines, which record 
all SVC transfers, or just those SVC's in which an error return is made. 

There are other miscellaneous commands which give the user the facility 
to terminate the typeout at his terminal, to shorten the length of the line typing 
at the terminal, and to kill program execution. The user can also obtain statis- 


tics on his file space and share additional permanent disks with other users. 
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Each of the CMS commands is described briefly in Section VI. 
A sample terminal session for CMS running under CP-67 is shown 


and described in Section VII. 
CMS Batch Monitor: 


As well as being a conversational monitor, CMS provides a batch faci- 
lity for running compile, load, and go type jobs. The CMS batch monitor 
accepts a job stream from a tape unit or the card-reader and writes the output 
either on tapes, the printer, or the card-punch. The job stream can consist 
of a System/360 Operating System SYSIN job stream with FORTRAN (G), 
Assembler (F), and PL/I (F) compile load and go jobs calling cataloged pro- 
cedures or it can comsist of CMS commands along with control cards and card 
decks for compile, load, and go jobs for the supported compilers. 

Just as the conversational CMS does, the batch monitor can run from 
either a virtual machine or a real machine. Under CP, it can be used as a 
background monitor along with other conversational CMS users. 

To eliminate the possibility of one job modifying the CMS nucleus in 
such a way as to effect the next job, CMS is re-IPLed before each job begins. Files 
can also be written onto the batch monitor's permanent disk and then punched 
or printed, such as files written by Fortran programs; these files should be of 
limited size and considered as temporary, as they are erased between each job 


control card. 


Te se 


V.Control Program Console Functions 


Each of the CP-67 console functions that can be issued by a user from 


the termina! is described below. 


BEGIN 


CLOSE 


DETACH 


DIAL 


DISPLAY 


DUMP 


EXTERNAL 


IPL 


LOGOUT 


MSG 


QUERY 


READY 


RESET 


SET 


STORE 


begins execution at the specified address or, if no address 
is given, at the location at which execution was interrupted. 


releases the spooling areas containing input from the card 
reader or output to the printer or card punch. 


removes the specified device from the user's virtual 
machine configuration. 


is used in place of LOGIN to connect a user's terminal with 
a viutual telecommunications operating system or a virtual 
time-sharing system. 


typés at the terminal the contents of the specified register(s), 
core location(s), or program status word. 


prints the contents of the specified register(s), core 
location(s), or program status word on the offline printer, 


simulates an external interrupt to the virtual machine, 
causing control to pass to the CMS DEBUG command when 
CMS is entered, 


simulates the Initial Program Load sequence on the specified 
unit. 


releases the user's virtual machine, including his temporary 
disk area, and closes any spooling areas which have not 
been released, 


types out the specified message at the terminal of the person 
whose USERID is specified. 


types out either the number of users logged onto the system, 
the names of these users, or the maximum number of users 
allowed to log on, 


simulates a device end for the specified unit. 


simulates the system reset key on the 360 console by re- 
setting any pending I/O interrupts. 


controls the saving of virtual card-reader files and the 
typing of messages at the terminal. 


replaces the contents of the specified register(s), core 
location(s), or program status word with the specified 
information. 








TIMER 


XFER 


VI. CMS Commands 
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controls whether real time or CPU time is maintained 
for the virtual machine, 


controls the passing of files betwcen users. 


Each of the commands that can he issued by a user to CMS are de- 


scribed below. 


ALTER 


ASSEMBLE 


CLOSIO 


CLROVER 


COMBINE 


DEBUG 


DISK 


DUMPREST 


ECHO 


EDIT 


changes all or part of the identifier (filename, filetype, 
and filemode) of a file stored on the user's permanent 
or temporary disk without altering the contents of the file. 


converts assembler language source code into relocatable 
object code using the OS/360 F level assembler. 


signals the Control Program that I/O to offline unit 

record equipment has been completed and that the spooling 
areas for this I/O may be processed. CLOSIO is generally 
issued automatically by the commands which access unit 
record equipment. 


clears overrides set by the SETERR and/or SETOVER 
commands and causes all recorded trace information to 
be printed on the offline printer. 


copies the specified file(s), concatenating them in the 
order given, into a new file which is placed on the user's 
permanent or temporary disk and assigned the specified 
identifier. 


allows the user to stop and re-start programs at specified 
points and to inspect and change the contents of registers, 
core locations, and hardware control words online, 


causes a CMS disk file to be punched out or read in from 
cards which are in CMS card format, 


dumps the contents of an entire disk to magnetic tape or 
restores the contents of an entire disk from magnetic tape. 


tests terminal line transmission by repeating as typeout 
whatever is typed in by the user. 


allows the user to create card-image files on disk and to 
make changes to existing files from his terminal. 


ERAS] 





icy 


EXEC 


FINIS 


FORMAT 


FORTRAN 


GENMOD 


GLOBAL 


KE 


KO 


KT 


KX 


LISTF 
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deletes the entry for a specified file (or files) from the 
appropriate directory, rendering the file inaccessible 
to the user, and freeing the disk area containing that file. 


executes a file containing one or more CMS commands, 
allowing a sequence of commands to be executed by 
issuing a single command. 


closes the specified file (or files) by writing the last record 
of that file on disk, updating the User File Directory, and 
removing the entry for that file from the user's table of 
active files. 


prepares the user's permanent or temporary disk area for 
CMS use by writing blank records over the currently stored 
information. 


converts Fortran language source code into relocatable 
object code using the OS/360 FORTRAN G compiler. 


creates a non-relocatable core-image file on the user's 
permanent disk which is a copy of the contents of core 
between two given locations. 


specifies (1) macro definition libraries to be searched 
during the assembly process or (2) text libraries to be 
searched when loading files containing relocatable object 
code, 


truncates information currently being typed at the terminal 
to 72 characters per line.’ This truncation will remain in 
effect for the duration of the currently executing command 
or user program. 





clears overrides previously set by the SETOVER or SETERR 
commands and causes all trace information recorded by 
these commands to be printed on the offline printer. 











stops typeout at the terminal for the duration of the currently 
executing command or user program. 


terminates the currently executing program, updates the User 
File Directory, and logs out from CMS, transferring control 
to the Control Program. 


either types out at the terminal the identifier and size of the 
specified disk file(s), or creates a file on the user's per- 
manent disk containing information for use by the EXEC 
and/or $ commands. 


LOAD 


LOADMOD 


LOGIN 


LOGOUT 


MACLIB 


OFFLINE 


PLI 


PRINTF 


REUSE 


SCRIPT 


SETERR 





SETOVER 


reads the specified TEXT file(s) -- containing relocatable 
object code -- from disk, loads them into core, and 
establishes the proper linkages. 


reads a MODULE file -- which is in non-relocatable 
core-image form -- from disk and loads it into core. 


causes the user's permanent disk files to be either saved 
or deleted, as specified, If LOGIN is not issued, the 
files will be saved. 


compacts the User File Directory, executes any CMS 
command specified as an operand, and logs out of CMS, 
transferring control to the Control Program. 


generates or adds to a specified macro library, or types 
out the contents of the dictionary of that library. 


creates a disk file from card input, prints a disk file on 
the offline printer, or punches a disk file on cards. 


converts PL/I language source code into relocatable 
object code using the OS/360 PL/I F compiler. 


types at the terminal the contents of all or part of a 
specified disk file. 


reads the specified TEXT file(s) -- containing relocatable 
object code -- from disk and loads them into core, 
establishing linkages with previously loaded files and 
changing the default entry point of these files to that of 
the first file specified in the REUSE command. 


either (1) allows the user to create arbitrary alpha- 
numeric text files on disk and to make changes to 
existing files of this type from the terminal or (2) types 
out the contents of the specified file, formatting it as 
indicated by control words contained in the text. 


sets error overrides which will cause trace information 
to be recorded for each SVC-called program which returns 
with an error code in general purpose register 15. 


sets normal and error overrides which will cause trace 
information to be recorded for all SVC-called programs -- 
both those which are executed normally and those which 
return an error code in general purpose register 15. 








SNOBOL 


SPLIT 


START 


STAT 


TAPE 


TXTLIB 


UPDATE 


USE 
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converts a card-image file in Snobol source language 
into SPLI interpreter language and executes SPL1 
programs. 


copies the specified portion of a card-image file and 
appends it to a second specified card-image file. 


begins execution of the loaded programs(s) at the specified 
or default entry point and passes the address of a string of 
user arguments to the program(s). 


types statistics regarding the amount of permanent and/or 
temporary disk space used or compacts the User File 
Directory. 


writes the contents of CMS disk files of any type or size 
onto magnetic tape, or restores these files by writing them 
from tape onto disk. 


either (1) generates or adds to a specified text library, 

(2) types out the contents of the dictionary for that library, 
or (3) creates a file containing a list of entry points and 
control section names contained in that library. 


updates the specified disk file with a file containing control 
cards, where each control card indicates whether the 
information immediately following it is to be resequenced, 
inserted, replaced, or deleted. 


reads the specified TEXT file(s) -- containing relocatable 
object code -- from disk and loads them into core, estab- 
lishing linkages with previously loaded files. 


executes a file containing one or more CMS commands, or 
loads into core a file which is in either core-image form 
or relocatable object code and begins execution of that 
file, 
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VIL. CP-67/CMS Terminal Session 





A sample terminal session is given on the following pages, User 
input is in lower case; typeout from the system appears in upper-case. The 


following is a description of the terminal session: 


After logging in to CP and utilizing CMS, a LIST command is issued to 
obtain a list of all files stored on user CSCI1's permanent disk, The file 
"MAIN FORTRAN" is then created and filed on the user's permanent disk. 
Compilation of the file is terminated due to program crrors (indicated by a 

$ symbol below the error encountered). The file is then modified and edited 
to correct the line in error, and the new source file stored on disk. Again an 


error is encountered and the file re-edited. 


After a successful compilation, the $ command is called to load the file 
into core and execute it. LOAD and START perform the same functionas $, 
as shown. Specifying the XEQ option with the LOAD command will also cause ex- 


ecution to begin after the file is loaded. 


LISTF and ERASE commamsare used to selectively list and erase files, and 
the PRINTF command is used to print all and then part of the contents of a 
file. KT causes typeout to be discontinued if entered after the attention key 


is hit twice. 


The OFFLINE command punches or prints the specified file on offline devices. 
STAT types out statistics regarding the amount of disk space used and remaining. 
The ALTER command changes the identifier of a file. KX, entered after hitting 
the attention key twice, stops execution of the current program and returns con- 


trol to CP. 
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A new copy of CMS is obtained by issuing the IPL console function and an 
EXEC file (consisting of CMS commands) is created and filed. The file is 
then executed by issuing the EXEC command, which will cause each of the 
commands contained in the file to be executed individually. Operand substi- 


tution is illustrated by modifying and re-executing the file using & arguments. 


Hitting the attention key once transfers control to the Control Program where 
the QUERY console function is issued to determine the number of users on 
the system, their names, and the message of the day from the operator. The 


BEGIN console function then returns control to CMS and the user logs out from 


both CMS and CP. 
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# 
CP/67 Online XDh65 Qsyosu 


1 cscl The user's id is specified upon logging in. 
ENTER PASSWORD: 

The protected password does not 
CP WILL BE UP UNTIL 1500 CONTINUOUSLY, print when entered. 
READY AT 09.55.29 ON 04/12/68 


ipl cms 
CMS...VERSION 4.0 - 04/01/68 


listf 
FILENAME FILETYPE MODE NO.REC. 
INDIAN LISTING Pl 003 


DUMPREST SYSIN Pl 009 
SUPERSCR SYSIN Pl 070 
MY FORTRAN Pl 001 
INDIAN = TEXT Pl 002 
FORTCLG EXEC Pl 001 
LOAD MAP ps 003 


DUMPREST SYSUT1 Pl 019 
DUMPREST SYSUT2 Pl 019 


FIN SCRIPT Pl 001 
TUES SCRIPT PL 001° 
FRST SCRIPT Pl 001 


DUMPREST SYSUT3 Pl 001 
DUMPREST LISTING Pl 007 
AGENDA SCRIPT Pl 001 
INDIAN FORTRAN Pl 001 
R; T=0.06 


edit main fortran 
FILE DOES NOT EXIST; WILL BE CREATED. 
INPUT: 
c main program April 12, 1968 
write (6,10) 


l0#format (' a = ')g———_____ The _ # is a logical tab character that inserts 
#read (5,20) a blanks and places the following characters 
20#format (8.3) typed on the line into column 7 of the card 
#write (6,25) a,x image in a FORTRAN file. 

#end 

EDIT: 

file 

R; T=0.11 


fortran main 
0004 20 FORMAT (8.3) 
$ 


01) ERR 13. SYNTAX 
COMPILATION CANCELLED DUE TO SOURCE PROGRAM ERROR(S). 
E(00032); T=0.32 
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edit main fortran 
EDITs 
p 20 


C MAIN PROGRAM APRIL 12, 1968 
WRITE (6,10) 

10 FORMAT (' A = ') 
READ (5,20) A 

20 FORMAT (8.3) 
WRITE (6,25) A,X 


END 
EOF REACHED BY: 
P 20 
1 /format/ 
10 FORMAT (' A = ') 
1 /format/ 
20 FORMAT (8.3) 
c /8/f8/ 
20 FORMAT (F8.3) 
u 2 
10 FORMAT (' A = ') 
e/ tf oly 
10 FORMAT (' A = 2°) 
f 20 ‘ 


20 FORMAT (F8.3) 
i #x = aw*2 


EDIT 
p 
X = Axx? 
t 
p 20 


C MAIN PROGRAM APRIL 12, 1968 
WRITE (6,10) 

10 FORMAT (' A = ?') 
READ (5,20) A 

20 FORMAT (F8.3) 
X = Axe2 
WRITE (6,25) A,X 
END 

EOF REACHED BY: 

P 20 

file 

R; T=0,51 


fortran main 
ERR 22 UNDEFINED LABEL 
25 
COMPILATION CANCELLED DUE TO SOURCE PROGRAM ERROR(S). 
E(00032); T=0.40 
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edit main fortran 
EDIT: 
1 /25/ 

WRITE (6,25) A,X 
i 25#format (' a = 'f8.3,' x = 20.3) 


p 
25 FORMAT (' A = 'F8.3," X = 20.3) 
c /20/' f£20/ 


25 FORMAT (' A = 'F8.3,' X = ' F20.3) 
file 
R; T=0.14 


$ mat g———_—The ¢ deletes the line. 
fortran main 
R; T=0.46 


$ main 

EXECUTION BEGINS... 

A=? 

a5 

A= 2.500 X = 6.250 
R; T=0.33 


2 


load main 
R; T=0.25 


start 

EXECUTION BEGINS... 

A=? 

3.1 

A= 3,100 X = 9.610 
R; T=0.05 


load main (xeq) 
EXECUTION BEGINS... 


A = ? 

3.2 ; 
A= 3,200 X = 10,240 
R; T=0.28 


listf main * 
FILENAME FILETYPE MODE NO.REC. 


MAIN LISTING Pl 003 
MAIN FORTRAN Pl 001 
MAIN TEXT Pl 002 
Rz T=0.03 


listf * listing 
FILENAME FILETYPE MODE NO.REC. 
INDIAN LISTING Pl 003 


MAIN LISTING Pl 003 
DUMPREST LISTING Pl 007 
R; T=0.01 


erase * listing 
R; T=0.03 


listf * listing - 22 - 
FILE NOT FOUND 
£(00002); T=0.03 


printf main fortran 


C MAIN PROGRAM APRIL 12, 1968 
WRITE (6,10) 
10 FORMAT (' A = ?') 
READ (5,20) A 
20 FORMAT (F8.3) 
X = Ax*2 
WRITE (6,25) A,X 
25 FORMAT ('A = 'F8,.3," X = ' F20.3) 
END 


R; T=0.06 

printf main fortran * 3 25. 

C MAIN PROGRAM APRIL 12 
WRITE (6,10) 

10 FORMAT (' A = ?') 

R; T=0.04 

printf main fortran 


C MAIN PROGRAM APRIL 12, 1968 
WRITE (6,10) 


10 
The ATTN key was hit twice to 
a ee enter KT for killing the typeout. 
¢ =U, 


offline punch main text@@@@fortran g¢—The four @ characters delete the 
R; T=0.07 previous four characters 


offline print main fortran 
R; T=0.06 


offline printce main listing 
FILE NOT FOUND 
E(00002); T=0,02 


listf 

FILENAME FILETYPE MODE NO.REC, 
DUMPREST SYSIN Pl 009 
SUPERSCR SYSIN Pl 070 

MY FORTRAN Pl 001 
FORTCLG EXEC PI 001 
LOAD MAP P5 003 
MAIN FORTRAN Pl 001 


DUMPREST SYSUT1 P2 019 
DUMPREST SYSUT2 Pl 019 


FIN SCRIPT Pl 001 
TUES SCRIPT Pl 001 
FRST SCRIPT Pl 001 


DUMPREST SYSUT3 Pl 001 
AGENDA SCRIPT Pl 001 
MAIN TEXT Pl 002 
INDIAN FORTRAN Pl 001 
R; T=0.05 


Pica 


stat 
P-DISK: 0142 RECORDS IN USE, 0258 LEFT (of 0400), 36% FULL (of 010 CYL.) 
R; T=0.02 


alter main fortran * mainone * * 
R; T=0.02 


listf main fortran 
FILE NOT FOUND 
E(00002); T=0.03 


listf * fortran 

FILENAME FILETYPE MODE NO.REC. 
MY FORTRAN Pl 001 
MAINONE FORTRAN Pl 001 
INDIAN FORTRAN Pl 001 


R; T=0.01 
$ main 
q—_—-. The ATTN key was hit twice to 
enter KX for killing execution of $. 
kx 


KILLING CMS EXECUTION... 

P-DISK: 0142 RECORDS IN USE, 0258 LEFT (of 0400), 36% FULL (of 010 CYL.) 
TOTAL CPU-TIME CIN SECONDS) = 11.18 

CP ENTERED, READY. 


ipl cms 3 
CMS...VERSION 4.0 - 04/01/68 


listf mainonn@e * <$————_ The @ deletes one character. 
FILENAME FILETYPE MODE NO.REC. 

MAINONE FORTRAN Pl 002 

R; T=0.03 


edit fortclgo exec 

FILE DOES NOT EXIST; WILL BE CREATED. 
INPUT: 

fortran mainone 

$@load mainone (xeq) 


EDIT: 
file 
R; T=0,10 


printf fortclgo exec 


FORTRAN MAINONE 
LOAD MAINONE (XEQ) 


R; T=0.04 


exec fortclgo 

FORTRAN MAINONE 

LOAD MALNONE (XEQ) 
EXECUTION BEGINS... 


Lave 


A=? 
3.4 

A= 3.400 X = 11.560 
R; T=0.86 


edit fortclgo exec 
EDIT: 

c /mainone/ &l/ «* g 
LOAD &l (XEQ) 

EOF REACHED BY: 

C /MAINONE/ &1/ * G 
file 


exec fortclgo mainone 
FORTRAN MAINONE 

LOAD MAINONE (XEQ) 
EXECUTION BEGINS... 


5.100 X = 26,010 


edit fortclgo exec 
EDIT: 

i &set err exit 
p 9 

&SET ERR EXIT 
FORTRAN &1l 
LOAD &l (XEQ) 
EOF REACHED BY: 
P 9 

file 

Rs T=0.11 


edit mainone fortran 
EDIT: 
p 4& 


C MAIN PROGRAM APRIL 12, 1968 
WRITE (6,10) 

10 FORMAT (' A = ?') 

b aa 
FORMAT ('A = ?') 

file badone 

R; T=0.15 


listf * fortran 

FILENAME FILETYPE MODE NO.REC. 
MY FORTRAN Pl 001 
MAINONE FORTRAN Pl 001 
INDIAN FORTRAN Pl 001 
BADONE FORTRAN Pl 001 

R; T=0.03 


ie 


exec fortclgo badone 
FORTRAN BADONE 
0002 FORMAT (' A = ?') 


$ 
01) ERR 02 LABEL 
COMPILATION CANCELLED DUE TO SOURCE PROGRAM ERROR(S). 
!!! £(00032) !!! 
R; T=0.44 


edit fortclgo exec 

EDIT: 

c /&1/&1 &2 & BY &5/ xg 
FORTRAN @&1 &2 &3 &4& &5 
LOAD &1 &2 &3 &4 &5 (XEQ) 
EOF REACHED BY: 

C /&1/&1 &2 &3 &h &5/ * G 
file 

R; T=0.12 


exec m@fortclgo mainone 
FORTRAN MAINONE 

LOAD MAINONE (XEQ) 
EXECUTION BEGINS... 


A = ? 
Le9 
A= 1.900 X = 3.610 
R; T=0.93 
The ATTN key was hit once to enter CP, 
q user 
10 USERS 


q user names 
CURRENT USERS ARE... 
MADNICK ON 029 
MARK ON O4C 
MEYER ON 047 
OPERATOR ON 009 
BAYLES ON O49 
CJONES ON 020 
ROSATO ON 027 


WHJ ON 024 

SEYMOUR ON O45 

LOVE ON 028 
q logmsg 
CP WILL BE UP UNTIL 1500 CONTINUOUSLY. 
begin <+—__———————— BEGIN returns control to CMS. 
CMS 

logout 


CMS LOGGING OUT... 
TOTAL CPU-TIME (IN SECONDS) = 2.99 
CP ENTERED, READY. 


1 
LOGOFF AT 12.06.06 ON 04/12/68 
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APPENDIX A 


Devices Supported by CP-67 


The minimum configuration required for CP-67 is as follows: 


2067-1 or 2067-2 Central Processing Unit 
2365 Core Storage Unit 

1052 On-Line Console Typewriter 

1403 Printer 

2540 or 2501 Card Reader 

2540 Card Punch 

2 2311 Disk Drives or 1 2314 Storage Unit 
2702 Transmission Control Unit 


Required features: 
#3233 15 Data-Set Adaptor 
#4615 IBM Terminal Ctl Type 1 
#8055 2741 Break (if 2741's used) 
RPQ #E-46765 Break Command (if terminals used) 
The devices that are supported in addition to the minimum configuration 
are described below: 
1051/1052 Model 2 Data Communications System 
Required features: 
#26903 Receive Interrupt Control 
#27428 Transmit Interrupt Control 
#5050 Master Station 
2741 (-1,2) Communications Terminals 


Required features: 


#4708 Interrupt 
#3255 Dial-up 


RPQ #E-40681 Receive Interrupt 
Desirable feature: 
RPQ #E-46151 Print Inhibit 

2250 Graphic Display 

2820/2301 Drum Storage Controller /Unit 


2303 Drum Storage Unit 
2400 Series Magnetic Tape Drives 
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APPENDIX B 


Devices Supported by CMS 


The minimum configuration for CMS is any System/360 with the 
following specifications: 


256K Core Storage 

1052 On-Line Console Typewriter 

1403 Printer 

2540 Card Reader/Punch 

2 2311 Disk Storage Drives or 1 2314 Disk Storage Unit 


CMS will also support the following additional devices: 


2 2400 Series Tape Drives 
1 additional 2311 Disk Storage Drive or equivalent 
2314 Disk Storage Unit 
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